Why Most But Not All Tables Are Bad
Posted By : mattyb 13th May 2007Why Most But Not All Tables Are Bad
Why are tables such a bad idea as a design mechanism? There are numerous reasons, but the ones we’re most concerned with in this context are:
- They result in load times that are longer than necessary.
- They encourage the use of inefficient “placeholder graphics” that further slow performance.
- Their maintenance can be a nightmare in which even minor changes “break” the entire layout.
Tables Mean Long Load Times
Most people don't know that Web browsers are deliberately designed to ensure that each table downloads as a single entity. So, none of the material that's contained in a table will be displayed until all the contents of that table are downloaded to the client machine, and available for display.
When the original, intended purpose of tables is taken into account, this makes sense. Tables were designed to display… well… tables of data. Each cell contained a value that was being compared to, or related with, the values of other cells in the table. Isolated bits of data appearing quasi-randomly would not do; the table was a single, integrated entity.
When designers began to rely on tables to contain all or most of the content of a Web page, they were also saddled with the consequences of this design decision. In addition to the apparent delay that many users experience as a result of tables displaying all at once, the sheer volume of HTML code that is required to create today's Web page layouts with nested tables can also add actual load time due to increased page size. Table-based layouts almost certainly account for more user concern over long page load times than any other single factor.
Avoiding this significant load time would obviously be A Good Thing.
Use of Transparent Images Slows Us Down
Even with the availability of tables as layout mechanisms, designers could not quite attain the detailed level of control over page design that they wanted.
Sometimes, for instance, a designer might need a bit more breathing room around one part of a table cell (something for which table design does not allow). This kind of precision was unachievable.
Early on, some designer came up with the notion of creating a transparent.gif image file—a tiny GIF image that had no visible content. By creating table cells to contain these transparent images, we could force extra room both vertically and horizontally into tables whose cells were designed to remain in close proximity to one another.
The problem is, given a table with dozens or even hundreds) of these images, and depending on a variety of other factors, the performance impact of transparent GIFs on a Web page can be significant. More importantly, however, this technique will often restrict the page to a fixed pixel size, and it clutters the page with images that have no actual meaning for the content of the page. As we'll see later, this severely impacts the ability for users with disabilities to make sense of your site.
Maintaining Tables is a Nightmare
The third reason why most tables are bad is that maintaining a complex array of deeply nested tables is a nightmare. If you use tools such as Macromedia Dreamweaver or Adobe GoLive to manage your sites and their designs, you can generally ignore the messiness of the nested tables that make the design possible.
But even these tools are not foolproof, and when they “mess up” (to use a highly technical term), amending the unsightly pages they create can be quite a challenge.
If you’re like most designers, and you wouldn’t be caught dead using an HTML-generating tool because you feel you gain more control and understanding if you hand-code everything, then you’ll be familiar with this problem.
The difficulty arises because, by necessity, tables have a fairly complex set of tags, even if they aren’t embedded within other tables. And when we have nested tables, well, we’ve got a clear case of the uglies alright.
The situation is further complicated by the fact that, unlike programming editors, HTML editors generally do not force or support the clean indentation of code.
So, finding the start and end points for a given table, row, or even cell turns out to be what software folks call a “non-trivial task.” While it’s true that a competent HTML coder or designer could make this problem more tractable, it’s never really solvable, no matter what we do.
When it’s OK to Use a Table
There is one notable exception to the cardinal rule that Tables are A Bad Thing. If you have tabular data, and the appearance of that data is less important than its appropriate display in connection
with other portions of the same data set, then a table is in order.
In general (though there are undoubtedly some exceptions to this rule as well), this means that the use of tables should be confined to the presentation of numeric or textual data, not graphics, multimedia data types, forms, or any other interactive user interface components.
About the Author:
Matthew Bagley is the owner of Paramiliar Design Studios(http://www.paramiliar.com)
Working with many companies their aim is to give your business the online potential it deserves.
Visit http://www.paramiliar.com/articles.html to find more articles written by Paramiliar Design Studios
Comments
Navigation
Latest Articles
